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Background of the invention 

1. Field of the invention 

The invention relates to systems for electronic commerce generally and more specifically to 
i o systems for electronic commerce in services. 

2. Description of related art 

The development of the Internet and more particularly of the World Wide Web have led to the 
explosive growth of electronic commerce, or e-commerce. The World Wide Web has made 
Web sites directly accessible from anywhere on earth, and has in the process so expanded 
possible markets and reduced transaction costs that it has opened a whole range of new 
possibilities for both very large and very small enterprises. The business of book selling can 
serve as an example: on the one hand, amazon.com® has in a few years become one of the 
giants of the book selling business; on the other hand, small dealers in specialized or old books 
are now easily accessible from anywhere in the world. 

At present, the advantages of e-commerce in increased access of vendors to customers of 
customers to vendors and in reduced transaction costs are being reaped only with regard to 
goods and standardized services. As one would expect, people are most comfortable with e- 
commerce where there is no need to see the goods or try them out before purchasing them, as 
is the case for example with personal computers, new books, or shares of stock. E-commerce 
in services has been limited to services that are so standardized that they can be represented by 
a ticket, a subscription, or a reservation. Examples are e-commerce in theater and concert 
tickets, information feeds, hotel reservations, or airline tickets. 

The increased access to customers and vendors and reduced transaction costs offered by e- 
commerce are potentially even more valuable with regard to non-standardized services than 
they are with regard to goods and standardized services. Examples of non-standardized 
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services are translating a document, transcribing a medical report, solving a mathematical 
equation, writing a computer program, writing a report, or doing legal or business research. As 
can be seen from the examples, non-standardized services have the following characterises: 
. because they are not standardized, they cannot be reified, i.e., represented by a ticket, 
5 reservation, subscription, or the like; and 

. because the providers of the non-standardized services are generally individuals or small 
businesses, there is no effective market mechanism for bringing purchasers and providers 
together or for determining prices. 
Often, the providers work on a part-time basis. For example, foreign engineering graduate 
,0 students in the Unites States have long supplemented their income by doing technical 
translation in their spare time. Similarly, lawyers who are staying home with their children 
often do legal research for other lawyers. 

In many cases, non-standardized services also have the following characteristics: 
15 . special training or experience is needed to do the job; and 

. the cost of the job depends on factors such as the job's length, its difficulty, and the tune 
the service provider is given to do the job. 

For instance, a translation of a French newspaper article will generally cost less than a 

translation of a French technical paper of the same length and the price will rise steeply as the 
20 period for completing the work gets shorter. 

From the point of view of a customer for such a non-standardized service, the first problem is 
to find someone to do it at all. The more specialized the service is, the less likely the customer 
is to know someone who provides it or to be able to judge whether the person the customer has 
25 found is in fact capable of providing the service. Once the person has been found, the next 
problem is setting a price: since there is effectively no market, the price generally ends up 
being unfair to one or another of the parties. Then there are all of the problems of dealing with 
small businesses or individuals arise: typically, they don't take credit cards and commumcaUon 
may be difficult or sporadic at best. Finally, if the job is not finished, is finished late, or ,s 
30 otherwise not properly done, the customer often has no practical recourse. 

The provider of a non-standardized service has the reverse problems, and the smaller the 
provider is, the more difficult the problems are. The first problem is of course finding the 
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customer. Advertising is expensive, and if potential customers are widely dispersed, there is 
often no cost-effective way of doing h. Once the customer has been found, setting a pnce » a 
vacuum is as hard for the provider as it is for the customer. The provider has little or no 
information about the customer's ability to pay, and once the customer has the deliverable, be 
it a legal opinion or a translation, the customer has little or no incentive to pay. When the 
customer does not pay, the provider, too, often has no practical recourse, since the srze of the 
transaction often cannot justify legal action to compel payment. 

The high transaction cost of locating qualified providers of non-standardized services has 
prevented some things from being done at all. For example, a manufacturer of a speaahzed 
product may want some feedback from potential users of the product; given the cost of locating 
the potential users, getting into contact with them, and finding out what their needs are the 
m anufacturer often simply decides to rely on what the salespeople think. On the other hand if 
some way could be found to make contact easy, many potential users would be glad to provule 
the feedback, particularly if they got some compensation for the time they spent doing tt The 
high transaction cost of locating customers has also discouraged people such as stay-at-home 
spouses, students, and consultants from providing non-standardized servtces. 

What is needed if the benefits of e-commerce are to be extended to commerce in non- 
standardized services is solutions to problems such as the following: 

. making customers for such services and providers of such services more access^ to each 

. ling for the credentials of the service provider and the quality and reliability of the 

service he or she provides; 
i . determining what the price for the service should be; 

. vouching for the ability and willingness of the customer to pay; 

• keeping track of the status of the job; 

. providing for communication between the customer and the service provider; 

. givi „g the customer enough access to the deliverable to decide whether the job was well 

o done but giving him complete access only after he has pa,d; 

. providing audit trails in case of disagreement between the customer and service provder; 

and 

. providing low-cost dispute resolution facilities for settling such disagreements. 
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It is an object of the present invention to provide solutions to these and other problems of 
expanding e-commerce to include non-standardized services. 

Summary of the invention 

The invention attains its object by providing a service dispatch system that mediates between a 
service requester and a set of service providers. The service dispatch system mediates wrth 
regard to the identities of requester and providers, with regard to assignment of a task 
requested by a service requester to a service provider, with regard to negotiation of a pnce for 
the task with regard to acceptance of a solution for a task by the service requester, with regard 
to payment of the price, and with regard to dispute resolution between the parties. Other 
embodiments may not mediate in all of these areas. The service requester and the semce 
providers have access to the service dispatch system by an interactive interface. In a preferred 
embodiment, service requesters and service providers interact with the service dispatch system 
via the Internet. 

The service dispatch system receives a task and a specification of a price from the service 
requester. The service dispatch system responds to this task posting by assigning one or more 
service providers to the task. When a service provider has a solution for the task, he or she 
posts the solution to the service dispatch system, which in turn indicates to the semce 
l0 requester that the solution is available. When the service requester indicates to the service 
dispatch system that he or she accepts the solution, the service dispatch system pays the serv 1C e 
provider the price and provides the solution to the service requester. The service dispatch 
system thus makes it possible for service requesters and service providers to easily locate each 
other and ensures that the service requester receives the solution and that the service proper 
25 receives the price. 

The semce dispatch system of the invention further permits users to define one or more 
profUes for themselves. Each of a user's profiles presents a different vie» of the user to other 
users of the system. Forexample, auser-s profile may indica* the expertise and educauon that 
,„ the user has for solving a particular class of task. Profiles a!so permit a service requester to 
post a task anonymously and a service provider to disclose only as much person* mformauon 
L is necessary to shov, competence in solving tasks of a particular class. When the serv.ee 
dispatch system assigns a task, i, assigns i, to one or more profues. When the semce 
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requester pays for a solution, the service dispatch system obtains rating information from both 
the service requester and service provider. The cumulative ratings for a profile are part of the 
profile and may be made available to service requesters or providers. The service dispatch 

system thus provides a market for service requesters and providers which provides serv.ce 
5 quality information, but otherwise provides as much anonymity as is desired between the 

participants and is therefore less affected by the prejudices of either the service requester or the 

service provider than traditional markets. 

When a service provider sets up a profile, he or she indicates his or her areas of expertise, and 
10 when a service requester posts a task, he or she classifies the task. The service dispatch system 
uses the information that it has about the classification of the task and the ratings of the profiles 
to select a number of service providers to whom the task might be assigned. In some cases, 
the service dispatch system will automatically assign the task to the selected service prov,ders; 
in others, it may provide a list of selected profiles to the service requester, with the final 
„ selection being made by the service requester. As will be explained below, the selection may 
be made on the basis of price. 

The service dispatch system peonits a service requester to establish a memod of detennining 
the price of the s«vice. In . preferred embodiment, establishment of to price may involve 
20 baIgatai ng between the service requester and the service provider o, a bidding system. In both 
cases, the service dispatch system mediates the bargaining and the btddmg. 

When a service provider posts a solution, the service request may either accept the solution, 
completely reject the solution, or request *a, it be modified. Where possible, the serv,ce 
25 dispatch sysKm will provide the requester with enough information about the solution to 
pel, an informed judgment of the solution's quality, but no, win, the entire solution until the 
requester has accepted and paid for it. 

The service dispatch syaem also mediates between service requester and service provider with 
3 o regard to payment. Each profile may include specifications of how the profile will pay .f.us 
fiTtioning as a service ret.ues.er and how i, is to be paid if i, is functioning as a 
provider. On accepting of a solution by a requester, the service dispatth system transfers 
payment from the requester to the provider. 
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* — ■» infcma,ion abou ' "* mBrac,,ons T 

service requesters and service provide* and abou. rejected and accepted solans to perm,, a 
M m Pl e.e audi, trai. .o be made of a action bemeen a service reaues«r and a serv.ce 
ZL. Additionally, one of .he services provided by .he service dispatch sys«m .a 
arbitration of a disputed transaction on the basis of*, audi. Ban. 

Other object and advantages win be apparen. «» *ose sMHed in *e a«s ,0 which the inven.ion 
pertains upon perusal of .he follo»ing Jtoaltol Describe* and drawing, wherem: 

Brief description of the drawing 

FIG lis anoverviewofasv SK mforhand!ingre,ues K for„on.sumdardi 2 edserv,ces-, 

FIG . , shows a ft. portion of ,he database used in a preferred embodiment of the sysKm of 

FIG . 3 Htsl second portion of the debase used in a preferred embodiment of the sysKm 

FIG . 4 s ° h lw S G aL portion of .he database used in apreferred embodiment of the system of 
FIG. 1; 

FIG. 5 shows the SQL definition of account record 205; 
, F1G.6 sr^ws,h«SQ L def 1 m.ionsofeduca.ionre=ord2.7a Jrf exper. I serecord22 1 ; 

F ,G.7shows,heSQLdef,„i.ionofpaymemodrecords2<»and2 13 ; 

FIG. 8 shows me SQL defnuuons of profUe record 225 and ranng records 2», 233. and 

FIG 9 shows the SQL definitions of task record 249 and solution record 269; 

F.G. » shows the SQL definitions of pricing scheme record 307, negotiation state record 31, . 

5 and negotiation history record 265; „^„ 7 . 

FIG 11 shows.heSQLde fi ni„on 5 ofprovidcrsu, te record26.andacuv,y re cord257 

KG. n lws .he SQL demons of aatus history record 253. solution htstory record 273. 

and message record 409; 
FIG. 13 is an overview of database manipulation routines 115; 
30 FIG. 14 is the initial Web page of the user interface; 

FIG. 15 shows a first part of the user interface for setting up an account; 
FIG. 16 shows a second part of the user interface for setting up an account; 
FIG. 17 shows a second part of the user interface for posting a quests; 
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FIG. 18 shows a first part of the user interface for posting a question; 
FIG 19 shows the user interface for viewing a solution; 
FIG. 20 shows the user interface for rating a service provider; 
FIG. 21 shows the user interface for allocating payments among semce providers; 
FIG. 22 shows the user interface for viewing messages; 
FIG 23 shows the user interface for posting a project; 
Fir 24 shows the user interface for selecting a pricing scheme for a task; 
FIG. 25 tows the user interfaces for categorizing a tasK and for setting up sealed .ddmg for 
the task; 

FIG 2« shows the user interface for viewing open tasks; 
FIG 27 shows the user interface for finding service providers; 
F.G. I8 shows the user interface whereby a servic* provider may view posted tasks; 
FIG 29 shows the user interface whereby a user can view messages concerning tasks, 
FIG 30 shows the user interface whereby a user can view tasks; 
, F , & 3Ishows.he„seri«erfacewherebyausercanedi,hisorheraccoun, ; 

FJG 32 shows the user interface whereby a user can edit his or her profiles; 

It 33 Iws the user interface whereby a user - view his or her baiances tn system 10 

"g M tTs the user interface whe»by a user can view «sk messages for tasks mvolvmg 

« ,7 sTs! user interface whereby a service reouester reives an offer from a serv.ce 
K1G . user tnterfac whereby a service reo.ues.er accepts an offer from a s^vice 

S FIG. »d - <— — ' ^ " ° f * "* 

and 

FIG. 40 is a flowchart of the operation of system 101 . 

^ in the drawing have three or more digits: the two right-hand digits are 
30 Reference numbers m the drawing n 

reference numbers in the drawing indicated by the remannng drgrts. Thus.anrte 
reference number 203 first appears as item 203 m FIG. 2. 



7 



- 9 - 



WO 00/29989 



PCTAJS99/27270 



Detailed Description 

The following Detailed Description will begin with an introduction explaining the utility of a 
system for e-commerce in non-standardized services, termed herein a service dispatch system, 
and providing an overview of its operation, will then present an overview of a preferred 
embodiment, and will finally describe details of a preferred embodiment, includmg the 
structure of the database used therein and the user interface for the system. 

Introduction to the service dispatch system 

The service dispatch system of the invention is the first-of-its-kind mechanism for transact 
"web-deliverable" services on the Internet. The service dispatch system is designed to prov.de 
a complete environment for matching a given service task to a qualified service provider, and 
tracking the transaction from the posting of the task through the payment for services rendered, 
in between, the service dispatch system manages all necessary interactions between the pames 
involved in the exchange. A task is to be understood here as anything in a range from an 
answer to a question through a large software engineering or research project. In a preferred 
embodiment, there are two subtypes of tasks: questions, where all that is required is *. a 
service provider who knows the answer provide it to the service requester, and projects, where 
the service provider must undertake considerable independent effort to provide the requested 
service. 

The service dispatch system provides a mechanism to out-source tasks via the Internet 
Whether the task is the transition of a document, transcription of a medicai report, sol™* a 
mathemattca. conation, getting a legai opinion, or a consumer opinion, the serv.ee dtspatch 
Item w,U find one or more peopie with the expose, ge, them working on « and send back 
L sohttion for accepumce. The service dispatch system matches ta.e„t with probiems and 
provides a medium for both parties to transact their business. 

B-commerce soiutions and services have to date been primari., directed ,0 the sale of tangibie 
JZ* as books, computers, cars. «c.) and seconds directed to branded «rv,ces(such 
1 airiine tick... hote! reservations, newsfeeds) which typicaUy have phystcal realtor* (the 
flight the hotei, and so fonh). Meeh*»sms typically feus on negotiating a pnc. agreement 
*e services provided are generaliy fixed and the buyer finds the services by externa! n«_ 
Examples ilde the fixed price o, a company store (e.g. de,,com, the aucuon mode! of 
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ebaycom or the reverse auction model ofpriceline.com. The one paradigm involving non- 
standardized services is an old one; the classified pages brought straight into the electronic age. 

The service dispatch system is qualitatively different, in that it is intended to provide the 
substrate for a free market for any services that are deliverable via the Web (specifically, are 
reducible to text, images, audio, video, or other computer formats). Obvious possibles 
include (but are not limited to) photographs, recordings, graphic design projects, banner 
advertising design, document translation, book reviews, mathematical problem solutions, 
programming tasks, medical transcriptions, and so forth. It should be noted, however, that the 
task management features of the service dispatch system are also usable for services that are 
not deliverable via the Web. 

The service dispatch system is not just another classified service. Unlike a classified page, the 
service dispatch system provides specific mechanisms for linking service providers and 
service buyers and managing all of their transactions in a secure fashion. It proves a 
complete market, in which both parties can have the security provided by a well-defined 
process for the exchange of services. 

The service dispatch system provides the security of a full audit trail and payment typically via 
zero-knowledge or "ambiguated" solution interaction (for example, a company rmght buy 
photographs based on low resolution previews). Moreover, full arbitration is available m all 
cases (and all necessary information for arbitration is automatically logged, making complamt 
resolution easy and fair). 

, Furthermore, the service dispatch system permits both parties to be partially or ntlly 
anonymous. As such, it is we.i-sui.ed to facilitate the exchange of servtces based on sk,l 
alone, without reference ,0 outer prejudice, A company buying a banner ad grapmc does not 
need to know the race. sex. age. or anyUting else about the person who created the ad. as long 
as it looks good. The service dispatch system makes this notion a reahty. 

0 The service dispatch system is designed to reduce the granularity level of service exchange; it 
is intended to facilitate the transfer of services which are too small to be handled by 
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contemporary means (i.e. hiring a new employee), in a way which is much faster and more 
reliable than posting a classified ad. 

For small, irregular tasks, the service dispatch system is designed to provide a cheaper and 
easier solution than traditional contract work; it is specifically targeted at helping small 
businesses with limited funds meet their needs for specific services in a timely and efficient 
fashion. 

Moreover, the service dispatch system is designed to permit the utilization of the skills of a 
vast body of workers which are underutilized in today's economy. Workers who cannot take a 
regular job, for a variety of reasons, can use the service dispatch system to sell their special 
expertise on a time available basis. For example, the service dispatch system is ideally 
targeted at students - a highly skilled population which is inaccessible due to time constraints. 
The service dispatch system is also ideal for at-home parents and part-time workers; in every 
case, the structure and format of the exchange permit the sale of skills in a fluid, flexible way 
consistent with the outside constraints. 

Finally, the service dispatch system creates a truly global and 7x24 hour market for services, 
allowing service buyers to utilize talent outside their geography and allowing talent to find 
markets outside its local economy. 

Examples of services which may be provided via the service dispatch system 

1 Translation Tasks: 

You have a document you want translated from English to French. You can send the 
document to the service dispatch system in a number of ways. If it's a text or .pdf file, just 
upload it via the web. If it's a handwritten document, you can mail it and the service 
dispatch system will scan and upload it. 

2. Transcription Tasks: 

You have an audio tape of a doctor's notes or handwritten notes you want transcribed. Send 
the tape or the paper and the service dispatch system will convert it to digital form and 
upload it. You can ask the service dispatch system to only show that task to qualified 
service providers (medical transcribers) and to show you a list of the one's 
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interested/available for you to assign the task to. Once assigned, the service provider will 
work on the task and upload their result. 

3. Legal Opinion Tasks: 

You want to know your rights as a tenant in a given town. Submit a legal opinion task 
describing your situation. The service dispatch system will show it to lawyers with that 
expertise and assign it to one of them. Their response will include references to check their 
credentials. 

4. Problem Tasks: 

You are working on a dissertation and need a solution to a complex mathematical formula. 
Submit a mathematical problem task and request that it be shown as widely as possible and 
that you will pay for the result. Mathematicians and students who are users of the service 
dispatch system will see it, and the first to solve it will get the task. 

5. Opinion Tasks: 

You want to conduct a survey of what people think about a political issue. Submit an 
opinion task with your questions (using the service dispatch system's survey tool) and 
specify how many people you want the opinions of and how much you are paying for each 
opinion. The service dispatch system will display your task, provide them with an .nterface 
for taking answering your questions and send the answers to you in both full and summary 
forms. 

You want to know if people in a particular country think you would look better with one 
hair style or another. Post that question on the service dispatch system along with the 
different photographs, and specify how many respondents you want and from what 
country. The service dispatch system will provide you the answers. 

6. Photography Tasks: 

You need a photograph of a sunset over the Serengeti. You post it as an open to the pubhc 

task. 



7. Audio Tasks: 
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You need a recording of the sound of a koala bear. You post it as an open to the public 
task. 

8. Graphic Tasks: 
Banner ad design. 

Drafting services. Service buyer submits scanned sketch, service provider returns drawing. 

9. Programming Tasks: 

You need a banner ad for your company... 
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10. Reward Tasks: 

Have you seen this man, he's wanted by the FBI... 
Have you seen this child, he's been missing for.. 

15 11. Competition Tasks: 

Design entries are invited for a new garden at the corner of Prospect and Mass Ave. 
Entries accepted until midnight December 31. Winners will be announced by March 1 
First prize will receive .... 

20 12. Research Task: 

Legal research. Service buyer is a lawyer, service provider is a paralegal. 
Reference library services, trademark searches, etc. 

13. Marketing Research Tasks: 

25 Will pay $x for each opinion on this product. 

14. Time Sharing Tasks: 

Will pay $/hour for compute time to run this applet. 

30 15. Programming Task: 

Need JavaScript code that will pop-up a window when... 

16. Book Review Task: 

12 
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Need a 1000 word review of the new "Internet for Dummies" books. 

17 Movie Review Tasks: 

Launching a new movie site. Looking for 100 word reviews of current releases. 

18. Tax preparation Tasks: 

19 Advertising via survey tasks: 

Have a single question survey asking opinion of the enclosed banner ad. Sendee provder 
(thc survey taker) paid viewing ad and clicking "like" or "don't like" button. Service buyer 
(advertiser) guaranteed viewership of their message and feedback on its reception. Bong 
paid to view advertising. 

20. Arbitration Tasks: 

Arbitration service for small disputes. 



Functional description of the service dispatch system 
The functions performed by the service dispatch system are the following : 
1 User account creation and login 
20 2. Task posting 

3. Task assignment and negotiation 

4. Task solution submission 

5. Task solution review and acceptance 

6. Payment 

25 7. Task solution delivery 

8. Dispute arbitration 

9. Communications management 

10. Privacy and security 

30 l^ILjjjirrnunt 1T"ttifr ? nd login 
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service provider profiles. The profiles are mechanisms which permit users of the system to 
present different aspects of themselves to it. When a user account is created, the system will 
prompt the user for a usemame and password which are stored in a persistent database and 
thereafter used for login authentication. For a given session, the system will allow the user 
(having created an account in the past) to login as either a service requester or a service 
provider. Prior to entry to the system, the user must enter the usemame and password for a 
valid account in the persistent database. 

b. service provider profile creation 

The user can create one or more service provider profiles via a Web form. Each profile 
collects information including at least a handle, an e-mail address for correspondence, payment 
information, and information regarding the kinds of service they wish to provide. The profile 
may optionally collect further information such as name, address, description, and so forth. To 
be eligible for certain kinds of tasks, evidence of certification may be collected as well (see 
certification management below). Profile information is stored in a persistent database and can 
be edited at any time by an authenticated user. 

c. service requester profile creation 

The user can create one or more service requester profiles via a 

web form. Each profile collects information including at least a business name, business 
address and phone, an e-mail address for correspondence, and payment/billing information. 
The profile may optionally collect further information such as a description. To be eligible to 
post certain kinds of tasks, evidence of certification may be collected as well (see certification 
management below). Profile information is stored in a persistent database and can be edited at 
any time by an authenticated user. 



d certification management 

In order to be eligible for certain classes of tasks (either for service buying or service 
30 provision), outside certification (e.g. license to practice law) may be collected. Such 
certification is collected in the form of text information (i.e. license number) and/or uploaded 
files. Before certification is granted, various off-line processes may occur (i.e. a phone call to 
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the relevant registry). All information is stored in the persistent database and may be edited at 
any time by an authenticated user. 

?, Tfl«ft posting 

A task can be posted by any registered user with a service requester profile. The posting of the 
tasks involves the collection of at least the following pieces of information (if not explicitly 
provided then default values will be used) : 

a. task category (translation, transcription, photography, and so forth) 

b. task title 

c. short description 

d. task body 

e. display options (public, public to qualified providers, private, etc.) 

f. solution options 

1 . number of solutions solicited 

2 . number of solutions actually purchased 

3. method in which purchased solutions will be selected (i.e. auction, competition, 
first-in) 

g. pricing information (maximum price, whether bargaining is acceptable, etc.) 

h. assignment information (whether the task can be automatically assigned, methods in 
which assignment is confirmed, etc. [see Task assignment below]) 

i. time constraints (for various phases of task resolution) 

All of the task information is stored in the persistent database. However, the task can be edited 
only prior to assignment (see below) by an authenticated user. 



Task assignment 

The system permits three possible methods of task assignment, automatic assignment, manual 
assignment, and posting for solicitation. The task may be switched between methods at any 
time (although resulting behavior may depend on previous assignments made). 

In automatic assignment, a number of service providers (the number depending on the number 
of solicited solutions above and possibly other information) are chosen based on criteria 
including time in the system, performance history, and stated category interests. These service 
providers are notified of the interest of the buyer in assigning the task to them. 
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In manual assignment, the buyer is provided with the opportunity to browse the space of 
service providers to select some number to be notified of opportunity of assignment. The 
browsing process involves some view of the total space of service providers, constrained by 
such factors as interest, time in the system, performance history, and possibly other things. 

In posting for solicitation, the task description is made accessible to a relevant community of 
service providers and assignment requests are solicited. 

All assignment decisions are logged in the persistent database and cannot be edited by the 
authenticated user (they are stored for arbitration purposes). 

In some cases, assignment decisions will be made on the basis of price negotiations. A 
preferred embodiment of the system supports direct negotiations between the service requester 
and interested service providers and also supports bidding systems, including reverse auction, 
sealed bidding, and Dutch auction. 

Notification of service requesters involves a message (sent through the internal messaging 
system and/or e-mail) stating the interest of the service provider as well as providing some 
amount of information about the task. Depending on privacy settings, varying degrees of 
information about the service requester will be provided. The information about the task 
includes at least a short description, information about price, information about acceptance 
criterion, and information about the assignment process (such as how many others were 
notified, and so forth). 

A notified service requester may respond to such a message in one of four possible ways. 

1 . The service provider may accept the assignment request. 

2. The service provider may conditionally accept and make a counteroffer regarding terms 
of the assignment. 

3. The service provider may reject the assignment request. 

4. The service provider may ask for clarification regarding the assignment request. 
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The service requester will be notified of all such response decision. 

In response to information from a service provider, the service requester may respond as 
follows : 

5 • If the service provider has accepted the assignment request, the service requester can either 
confirm the assignment or reject the service provider according to the protocols specified in 
the task description. 

• If the service provider has rejected the assignment request, no response is permitted. 

• If the service provider has conditionally accepted and made a counteroffer, the service 
10 requester may accept the offer (which has the same effect as if the service provider had 

accepted the assignment request, except some piece of the task description has been 
modified), may respond with a counteroffer (which permits a response from the service 
provider as above), or may reject the service provider. 

The cycle of counteroffers will continue until a rejection occurs or an agreement is reached. 
15 This cycle may be automated and coordinated between assignment requests (i.e. in an auction 

model). 

Notification and negotiation of assignment requests can continue until a total number of 
assignments specified (as solutions solicited) in the task description are confirmed. Once a 
20 service provider has been assigned a task, the service provider is then given access to the 
complete task body in the event that the task body was not made previously available. The 
access to the complete task body gives the service provider the information needed to do the 
task. 

25 4 Jfidc solution submission: 

Task solutions can be submitted in one of three ways. 

1 . A registered user possessing a service provider profile which has been assigned the task 

may submit a solution. 

2. A registered user possessing a service provider profile may submit a solution to a 

30 viewable task. 

3. A registered user without a service provider profile or a unregistered user may submit a 
solution to a viewable task (in the case of the unregistered user, this is public tasks only). 
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Solution submission in the latter two cases is only possible if the task has not been assigned to 
any service providers. 

When the service provider has completed the solution, the system permits the service provider 
5 to upload the solution as well as associated information, including at least either an 
"ambiguation method" or an uploaded ambiguated version of the task. 

Ambiguation is a process whereby the solution is "blurred" in some way so that (ideally) the 
buyer can verify the necessary features of the solution but does not actually have possession of 

10 the solution. Examples might include (but are not limited to) actual blurring of photographs 
(or provision of thumbnails), display of fragments of text documents or audio files, and so 
forth. The system will attempt to make provisions so that a service requester cannot assemble 
a complete solution by examining a number of different submitted solutions. If the service 
provider is unhappy with the default methods for the given task category, he or she may submit 

15 their own "ambiguated" version. 

Initially, all submitted information is placed in a temporary holding area (which may be logical 
or physical) in the persistent database and remains there until confirmation, at which time the 
ambiguated version of the solution (if it exists) and possibly other information is transmitted to 
20 an area accessible to the service requester. 

Submission of a solution is only possible as long as the task is "open", meaning that the 
provider has not already accepted as many solutions as specified in the task description. 

25 s x^ir solu t i o n nr" iflW an <* acceptance. 

When a service requester is informed that a solution is ready for his or her review, the system 
then permits the service requester to inspect aspects of the submitted solution (i.e. the 
ambiguated version) for acceptance decisions (and may also notify the service requester of any 
time constraints as specified in the task posting process for the completion or methodology of 

30 the acceptance process). 

The service requester can respond to the request in one of three ways. 
1 . The service requester can accept the solution. 
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2. The service requester can reject the solution outright. 

3 . The service requester can reject the solution and request changes. 

The distinction between cases 2 and 3 is the following. An outright rejection means the 
assignment of the service provider in question is cancelled and he or she can no longer submit 
solutions for the task. In addition, it may be that further assignment requests can be made (in 
order to generate enough potential solutions) depending on settings made during the task 
submission process. 

On the other hand, in case 3 the solution is rejected but the assignment remains and the service 
provider can upload another submission for future consideration (presuming the task has not 
closed in the meantime). 

The service provider in question will be notified by the system of any of these actions, along 
with information collected by the system regarding the reasoning of the service requester 
(which may include free text or selection of a checkbox from a list of rejection reasons). 

As part of the acceptance process, the service requester rates the expertise and conduct of the 
service provider in executing the task and the service provider rates the service requester. The 
ratings are retained in records associated with the task and the system also aggregates the 
ratings for tasks posted or performed by a profile to produce cumulative average ratings for the 
profile. The system may display the ratings to the service requester as part of the task 
assignment process. 

Pftvmept processing. 

The service requester can pay for the task solution via a variety of methods, including but not 
limited to a credit-card or pre-paid escrow account. The account is typically charged at the 
point of solution acceptance (where the charge includes both the price of the solution as quoted 
to the service provider as well as a surcharge for the use of the service dispatch system). 

The service provider is paid via a variety of methods, including but not limited to credit-card 
refund, check, wire transfer, or addition to an escrow account the service provider maintains 
with the system. The latter method may be done automatically for amounts below a certain 
threshold. Where solutions are provided by more than one service provider, the system 
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provides a mechanism which permits the service requester to allocate the price paid among the 
service providers. The system also provides a mechanism for adding a tip to the payment. 

7 , Tpsk sol ution delivery 

When a service requester accepts a solution, the complete and unambiguated solution is made 
accessible to the service requester for downloading or on-line viewing. 

3 , Dispute arbitration 

If a service requester rejects a submitted solution, the system will permit the service provider 
the opportunity to dispute the buyer's rejection. To participate in the system, all individuals 
must agree to binding arbitration in case of dispute. When a dispute is logged, a task is posted 
to the system which is accessible only to arbitrators. The mechanisms of the service dispatch 
system are used to perform the arbitration as described above, where the body of the task is the 
complete audit trail from the persistent database of all relevant information as well as the 
complaint text and response text collected by the system from the service provider and service 
requester involved in the dispute. 

The arbitrator can rule on the basis of information provided, or can request further testimony 
(subject to limitations on time for resolution) from either party involved. The arbitrators will 
then render their decisions and then the system will act on the decision. The decisions made 
can include the following options : 

1. In favor of the service provider, in which case the buyer is obligated to buy the 

solution. 

2. In favor of the service requester, in which case the provider must abide by the rejection. 
The arbitrator may rule that payment for the costs of arbitration be handled by either the 
service requester or the service provider (depending on the merits of the complaint) or by some 
combination thereof. Moreover, the service dispatch system may pay for some component of 
the arbitration under certain circumstances. 



O rnmnnin,frffiiflnff 1™napement 

All notification and communication between parties described above is carried out by an 
internal messaging system and/ or via e-mail. The internal messaging system is generally a 
message-driven system, meaning that responses may be generated only according to specific 
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situations (detailed above) or in response to a previous message. This enables arbitrary 
amounts of privacy protection. 

The messaging system also permits the posting of messages to public and semi-public forums 
(where the system may restrict access to these based on various user and profile criterion and 
information). 

Standard e-mail can be used as either a functional clone of the internal message system (i.e. all 
internal messages are copied to e-mail, and responses are mediated through an internal mail 
router) and/ or can be used simply as a notification device (for example, to specify that new 
internal messages have arrived and should be read). 



1 Q , p^vacy and security 

All financial transactions conducted over the world-wide web will be secure. Moreover, 
arbitrary other information distribution tasks may also be encrypted. The use of profiles in the 
system makes it possible for both the service requester and the service provider to control the 
extent to which they remain anonymous with regard to the task (although the system must 
maintain a certain amount of information to guarantee payment). 

Overview of operation of the service dispatch system: FIG. 40 

FIG. 40 is a flowchart 4001 of the operation of the service dispatch system. Dotted arrows 
indicate communications between the system and the user, service requester, or service 
provider. At operation 4003, a user 4001 registers with the service dispatch system; at 4005 
the user makes one or more profiles for him or herself; at 4009, a user 4001 who is functioning 
at this point as a service requester 4007 sends a task to the service dispatch system for posting. 
At 4011, the service dispatch system selects potential service providers 4013 for the task. 
Depending on the situation the service dispatch system may post the task for solution by all 
users of the system or even for the general public or may provide a group of one or more 
service providers among whom the service requester can select. Provision of the group is 
based on input from the service requester. The input may be the profile name of a service 
provider or a classification of the task. In the latter case, the service dispatch system uses the 
classification the areas of expertise indicated by the users when they submitted their profiles, 
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and the ratings of the users to select one or more service providers who are qualified to 
perform the task. The system then informs the selected providers of the task. 

At 4015, the task is assigned to one or more of the selected service providers. Depending on 
5 input from the requester, assignment may be done automatically by the service dispatch 
system, may simply result from an acceptance of the task by a service provider, or may be the 
result of negotiation, mediated by the system, between the requester and one or more of the 
providers. The negotiation may be simply a matter of offers and counteroffers or may take the 
form of bidding by several service providers. 

10 

When the task has been assigned to one or more service providers, the assigned service 
providers are given access to the materials provided by the requester for performance of the 
task, as shown at 4017. In some cases, the task is completely contained in the posting and this 
step is not necessary. 

15 

At 4019, one or more of the providers posts a solution to the task and the requester is notified 
of the fact that the solution has been posted. The requester is given access to the solution 
(where possible, the system ambiguates the solution) and then decides at operation 421 
whether to accept or reject the solution. In either case, the service provider is informed. If the 
20 requester wishes to have a different service provider attempt the task, the system returns to 
assign task operation 4015 to assign a different service provider (arrow 4022). If the requester 
merely wants the service provider to correct or improve the solution, the provider is so 
informed and later posts the improved solution, as indicated by arrow 4020. 



25 



30 



At 4023, the system performs the operation of paying the providers. In general, what will be 
paid is the price agreed on during assign task operation 4015, but the requester may also 
provide input specifying how the price is to be allocated among several service providers and 
also specifying a tip for one or more of the service providers. When the providers have been 
paid, the requester is given access to the unambiguated solution, as shown at 4025. 

Overview of a preferred embodiment of the service dispatch system: FIG. 1 
FIG 1 is an overview of a preferred embodiment of service dispatch system 101. Service 
dispatch system 101 is implemented in a dispatch system server 109 that has an Internet 

22 



- 24 - 



WO 00/29989 



PCT/US99/27270 



Protocol address and includes Internet interface 110. Internet interface 1 10 has a Web server 
1 1 1 that obeys the HTTP protocols and thus permits Web page viewing and file transfer, an 
email clientl22 that sends and receives email, and a cybercash client 121 which does secure 
monetary transactions. Dispatch system server 109 is accessible to its users 104 via their Web 
browsers and Internet 103. The users 104 include two groups: service requesters 105(a..n) and 
service providers 107(a..n). Of course, a given user 104 of dispatch server 109 may be a 
service requester 105(i) for one task and a service provider 1070) for another. 

In addition to Web server 111, dispatch system server 109 includes an application server 1 12 
and dispatch system database 125. Application server 1 12 includes a dispatcher 1 14 and a 
number of application server routines. These routines in turn read and write tables in dispatch 
system database 125. The information in dispatch system database 125 is organized according 
to the functions performed by dispatch server 109. Thus, user information 127 is information 
about the service requesters 105 and service providers 107 who use system 109. Task 
management information 129 is information that is used to manage a task from the time it is 
posted by a service requester 105(0 until the time all of the service providers 107(j.o) who 
successfully provided solutions for the task have been paid. Solution information 133 is the 
solutions; message information 135 contains the messages that flow among the users of system 
101 and between system 101 and the users in the course of operation of system 101. Archive 
information 137, finally, contains persistently stored information about tasks from system DB 
125, and thus provides the information necessary to make an audit trail. The numbers in 
parentheses are the reference numbers for the database tables that implement these classes of 
information in the preferred embodiment. These tables will be discussed in detail later. 

The routines of database manipulation routines 1 15 may similarly be grouped according to the 
database tables they manipulate. User routines 116 manipulate user information 127; task 
routines 117 manipulate task information 129 and task management information 131; solution 
routines 118 manipulate solution information 133; message routines 119 manipulate message 
information 135; and archive routines 120, finally, manipulate archive information 138. 

A user interacts with service dispatch system 101 as follows: using his or her Web browser, 
the user specifies the Web address of dispatch system server 109. Web server 1 1 1 responds 
which responds with an initial Web page that contains a menu which permits the user to select 
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among interactions with system 101; in response to the selection, Web server 1 1 1 provides an 
initial Web page for the desired interaction. For example, if the user is a service requester 
105(i) and wishes to view the tasks that are currently being performed for him or her, the initial 
Web page for viewing tasks will request that the user identify him or herself. When Web 
server 111 receives the user's identification, it will forward it together with an indication of 
what is to be done with the identification to dispatcher 114, which will respond to the 
indication by invoking a view tasks routine in task routines 1 17 with the user's identification. 
The view task routine will use tables in task management info 131 and task info 129 to return a 
list of the tasks that are currently being performed for the user and their status to dispatcher 
1 14, which will in turn pass the list on to Web server 111, which will incorporate the list into a 
Web page and return the Web page to service requester 105(d). From the Web page with the 
list, the user can view further Web pages, with Web server 1 1 1 and dispatcher 1 14 operating as 
just described. For example, the user may desire to see detailed information about a particular 
task on the list, and can select one task for detailed viewing. At the detail level, the user can, 
for example, review the bids for the task or if the task has already been given to a service 
provider 1070), send a message to service provider 107(j). 

Interaction between a user and dispatch system server 109 may always be at the initiative of 
the user, or dispatch system server 109 may send email to the user to inform the user of 
significant events. For instance, if a service provider 1070) has been selected for a task, a 
routine in task routines 117 may cause email server 122 to send an email message to service 
provider 1070) indicating that he or she has been selected and including the URL of the Web 
page that will contain the relevant information. 

Structure of dispatch system database 125: FIGs. 2-4 

System database 125 is a relational database, that is, the information in the database is stored 
tables. Each table is made up of records. All of the records in a given table contain the same 
field and fields of records in one table relate the records to records in other tables. FIGS. 2-4 
show the tables of dispatch system database 125 and the relationships between records in the 
tables. A single record is shown in each table, but of course, the same relationships may hold 
for other records. In general, there are two kinds of relationships: a one-to-many relationship, 
where a record in one table may be related to many records in another table, and a one-to-one 
relationship, where a record in one table may be related to only one record in another table. In 
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FIGS. 2-4, these relationships are indicated by arrows, with the direction of the arrow showing 
the direction of the relationship (if an arrow points from record 205 to record 217, it shows 
how record 205 is related to record 217) and an annotation on the arrow indicating whether the 
relationship is 1 to 1 ("1" on the arrow) or 1 to many ("m") on the arrow. Thus, each account 
record 205 may have a 1-to-l relationship with a buyer payment method record 209 and a one- 
to-many relationship with a profile record 225. 

Beginning the discussion of the structure with FIG. 2, the tables shown in FIG. 2 contain 
information about the users of system 101. Each user has an account record 205 in account 
table 203. A user may be either a service requester 105 or a service provider 107, or both, and 
the information in or accessible from a given account record 205 will depend on which role the 
user has. Thus, an account record 205 has a one-to-one relationship with a buyer payment 
record 209 and/or a provider payment method record 213. These records indicate how the user 
is to pay if he or she is a service requester and how the user is to be paid if he or she is a 
service provider. The account record also has one-to-many relationships with education 
records 21 7 and expertise records 221. The education records indicate the user's education and 
the expertise records indicates his or her expertise. 

In order to permit the user 104 to control the degree of anonymity that he or she has with 
regard to various kinds of tasks and to permit the user to be classified in different ways by 
system 101, the user is represented in the system not just by account record 205, but by at least 
one profile record 225. Each profile record permits the user to establish a different degree of 
anonymity, to respond to different classes of tasks, and to provide different displays of his 
credentials and expertise. A given task is posted by a profile belonging to the service 
requester, and responses to the task are by profiles belonging to service providers. In the 
following, therefore, a task is spoken of as being posted by a user, profile tuple and responded 
to by other user, profile tuples. The user's account record 205 may be related to many profile 
records 225; each profile record may be related to single rating records for expertise (229), 
conduct (233), and as a buyer (235). These ratings indicate how service requesters have in the 
past regarded the service provider's expertise and conduct in providing the service and how 
service providers have in the past felt about dealing with the buyer. Of course, a given profile 
record 225 will be related to a buyer rating record 235 only if the profile has functioned as a 
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service requester; similarly, the profile record 225 will be related to the expertise and conduct 
rating records only if the profile has functioned as a service provider. 

By means of profile-expertise record 241 and profile education record 245, profile record 225 
is linked to one or more of the education records 217 and expertise records 221. This 
arrangement permits service providers 107 to list per-profile sets of information about their 
expertise and education. For example, a lawyer who also had formal training in foreign 
languages might have a profile record 225 for legal tasks and one for translation tasks, with 
the legal profile record being related to education records 217 and expertise records 221 that 
showed his or her legal training and expertise and the translation profile record being related to 
education records 217 and expertise records 221 that showed his or her linguistic training and 
expertise. The aspect of a user which a given profile record represents is termed herein a 
profile for the user. The lawyer thus has a legal profile and a translation profile in system 101 . 

The remainder of the tables (247, 255, and 271) in FIG. 2 are all related to tasks and will be 
explained in more detail in the following. A given task is related to the user, profile tuple 
represented by a profile record 225 by a provider state record 261. As would be expected 
from the fact that a given user may be dealing with a number of tasks of a given kind, the 
relationship between a user's profile record 225 and the provider-state records is one-to many. 
Task records 249 for the tasks themselves are contained in task table 247 and the solutions for 
the tasks are contained in solution table 267. 

Continuing with FIG. 3, FIG. 3 shows the tables that are related to tasks in more detail. There 
is a single task record 249 for each task. Each task record 249 is related to one or more user, 
profile tuples. For a given user, profile, task tuple, this relationship is represented by the user, 
profile tuple's provider state record 261 for the task. Each user, profile tuple thus has a 
provider state record 261 for each task to which the user-profile tuple is related. 

The contents of a task record will vary according to whether it is related to a service requester 
profile, to one or more service provider profiles, or to both service requester and service 
provider profiles. With task records related to a service requester profile, the task record has a 
1-to-l relationship with a buyer payment method record 209 for the service requester, a 1-to-l 
relationship with a pricing scheme record 309 for the task, and a 1-to-l relationship with 
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activity record 257 for the service requester. Pricing scheme record 309 has a 1-to-many 
relationship with negotiation state record 313. There is a negotiation state record 3 13 for every 
service provider with which the service requester is currently negotiating for performance of 
the task represented by the task record. Each task record 249 may further be related to a 
number of status history records 253, each one of which keeps track of a change in the task's 
status. The status history records 253 for a task permit reconstruction of an audit trail for the 
task. 

Each provider state record 259 and each task record 249 may have many-to-one relationships 
with activity records 257. A given activity record 257 records a single transaction with regard 
to a given user, profile, task tuple. All of a task's activity records may be located from task 
record 249, and the activity records for a given user, profile, task tuple may be located from 
provider state record 261 for the tuple. When the profile to which activity record 257 belongs 
is functioning as a service provider with regard to the task, activity record 257 further has a 1- 
to-1 relationship to account record 205 for the service provider and to a provider payment 
method record 213. The latter record indicates how the provider to whom the profile belongs 
is to be paid. 

Provider state record 261 for a given user, profile, task tuple has a one-to-one relationship with 
task record 249 for the task and also has a 1-to-l relationship with negotiation state record 313 
for the user-profile-task tuple and a one-to-many relationship with solution record 269. Each 
solution record 269 represents one solution by the service provider, profile pair of the tuple for 
the task represented by task record 249. Solution history table 207 contains a record for each 
of the solutions provided for the task by the service provider-profile pair. There is a one-to- 
many relationship, finally, between each solution record 269 and a solution file record 315 
which contains the pathname for a file that contains part or all of the solution. As with task 
records, each provider state record 261 may be related to many status history records 253. 
Each swtus history record 253 records a change in the status of the user, profile, task tuple 
represented by provider state record 271. As with tasks, these status history records 253 are 
used to construct an audit trail. 

As is apparent from the above description, task-related tables 301 permit easy location of all 
task records 249 for each user-profile tuple. Task records 249 for user, profile, task tuples may 
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be easily located via provider state records for the user, profile, task tuples. Task category 
table 303, finally, permits location of task records 249 generally by the kind of task. 

FIG. 4 shows the tables that contain information about the messages exchanged between users 
of system 101. Depending on the embodiment and/or the choice of the user, the messages may 
remain internal to system 101 and be read or written using Web server 1 1 1. or dispatcher 1 14 
may use email client 122 to send a message that originated within system 101 to the recipient 
user via email and a user 104 may use his or her own email to send a message for another user 
to server 109 and server 109 may respond to that message by sending email to the recipient. 
Each message has a message record 409 in message table 407. Since messages concern tasks, 
have senders and /or recipients who are users 104 and may involve other users 104 as well, 
there may be one-to-many relationship between profile records 225, account records 205, task 
records 249, and message records 409. Messages may thus be located by user, by user, profile 
tuple, and by task. Dispatch system server 109 uses table seen records 405 to keep track of 
whether and when a giver user, profile tuple last examined a given task record 249 or message 
record 409. 

Details of tables in database 125: FIGs. S-12 

FIGs. 5-12 show the SQL query language declarations for the records in the chief tables shown 
in FIGs. 2-4. 

r> f ^ils of p rrnnnt record 205; FIG. 5 

FIG. 5 shows an account record 205. Each account record is indexed by the value in the field 
hd_account_id, 501, and when another record has a relationship to a given account record 
205^ it will include a field with the value of the given account record's field 501. The fields 
indicated by 503 track modifications of record 205; the fields indicated by 505 store the 
contact information for the user. Three of these fields are of particular interest: username is 
the name by which the user represented by record 205 is known to system 101; 
taxonomic_categories specifies categories to which the user may belong, for example, 
translator or lawyer, and permits searching for users by the categories they belong to; 
receive_email is a flag which indicates whether server 109 is to convert messages internal 
to server 109 to email and send them to the user represented by account record 205. 
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At 507, buyer_pay_method_id and provider_pay_method_id are record 
identifiers for the user's buyer payment method record 209 and/or provider payment method 
record 213. Which identifiers are actually present will depend on whether the user is a service 
requester, service provider, or both. The information at 509 is personal information which the 
user may prefer not to have visible to other users of system 101. The visible field 
indicates which of this information is to be made visible, status 510 indicates whether the 
user represented by the account is active or inactive. current_prof ile_id 51 1 indicates 
which of the profile records 225 belonging to account record 205 is presently of interest. At 
513 are shown fields that may contain a short question and a short answer. The user provides 
the question and answer when he or she registers and they are used to validate a user who has 
forgotten his or her password. 

At 515 is shown the field balance, which indicates the balance that system 101 currently 
owes the user 104 or that the user 104 owes system 101. Here and elsewhere in database 125, 
amounts of money are represented by an integer number of cents. The fields indicated by 517 
are time stamp fields that indicate the last modifications that have occurred in those records 
belonging to the user that have the record names indicated by the time stamp names. Thus, 
expertises_time indicates the most recent alteration of a record belonging to the user in 
expertise table 219. The times are represented as an integer number of seconds after a starting 
time fixed by system 101 . In a preferred embodiment, they are used to control caching of parts 
of database 125. The fields at 517 contain information about any escrow account which 
system 101 maintains for the user. upload_directory field 5 1 9, finally, is a field that 
indicates a directory in dispatch system server 109's file system into which files from the user 
are to be uploaded. 

prt piu of e Hyn tinn record 217 and expertise record 221 ; FIG. 6 

The fields that are the keys for these records are indicated at 601 and 609; fields 611 and 603 
track modifications of the records; owner ID 613 and 605 contain the value of 
hd accounted field 501 of account record 205 for the user whose expertise is or 
education is being specified. In general, a field named owner_id in a record contains the 
index of the record to which the record with the field "belongs", i.e., the record from which the 
record that contains the field is generally located. In record 217, the fields indicated by 615 
contain the actual information about the user's education; in record 221, the fields indicated by 
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607 contain the actual information about the expertise. In both cases, a visible flag permits 
the user to determine whether the educational information or the expertise information is to be 
visible to other users of the system. 

5 Details of provider payment metho d record 2 11 and buver payment method table 209: FIG. 7 
FIG. 7 shows the records for these tables. In the preferred embodiment, these tables are 
implemented as a single pa y_met hod table that contains the records for both tables. Which 
table a given record belongs to is indicated by the value of class flag 705. At 701 is seen the 
record's key, which is used in account record 205 and profile record 225. The fields at 703 

10 track modifications of the record; the remaining fields, indicated by 707, contain check account 
and credit card information that the system uses to make and receive payments. 

T>tm > 9 f profile reco rd 21 1 and rating records 229.233. and 237: FIG. 8 

As mentioned above, profiles in the preferred embodiment permit a user to control how he or 

j 5 she appears to other users of system 101. A given user may have a number of profile records 
211, each of which contains information specifying a different aspect of how the user interacts 
with system 101. For example, a user 104 may (but need not) have one profile as a service 
requester 105 and another as a service provider 107, and similarly, if a requester requests 
different kinds of services or a provider provides different kinds of services, he or she may 

20 have a different profile for each kind of service. When a user registers with system 101, the 
system provides the user with a default profile. The user may edit that profile or create other 
profiles. 

As shown in FIG, 8, profile record 225 has an index at 801 and change tracking information at 
25 803; owner_id 805 has as its value hd_account_id 501 for account table 205 for the 
user 104 that profile record 225 belongs to. name field 807 is the name for the profile 
represented by profile record 225. taxonomic_categories 809 indicates the kinds of 
services the profile represented by profile record 225 performs. It is used to locate potential 
service providers for a posted task. Email fields 811 indicate the email addresses for messages 
30 addressed to this profile; if inherit_emails so indicates, the email addresses are those 
specified in account record 205. As indicated at 812, profile record 225 may have the indexes 
701 for two records in the pay method table. 
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visible 813 indicates what information in profile record 225 is to be visible to other users of 
system 101; description 815 is a written description of the profile. At 817 is found the 
information that is used to rate the effectiveness of the profile; the information includes indices 
821 to three rating records 229, 233, and 237. At 819, finally, is found a collection of time 
5 stamps indicating the earliest task performed by the profile, the most recent task performed by 
it, and the most recent times at which various tables belonging to the profile were modified. 

In a preferred embodiment, the records of rating tables 227, 231, and 235 are all included in a 
single rating table. The SQL for the records in the rating table is shown at 229, 233, and 237 in 
10 FIG. 8. Each record is accessible by an index 821, has modification information 823, a class 
value 825, which indicates which of the three kinds of ratings the class contains, and then the 
current rating, which is cumulative. As shown at 825, the rating is specified as a sum of the 
past ratings, the number of ratings, and the average. 

15 TVtflilg nf task- record 249 and task solution record 269; FIG. 9 

Fig. 9 shows the SQL declarations for task records 249 and task solution records 269. 
Beginning with task record 249, there is one of these records for every user-profile pair 
concerned with the task Each task record 249 has its own task_id index 901; at 903 is seen 
the modification information; owner_id 905 has as its value the prof ile_id for the user- 

20 profile pair's profile. Structured_category 907 is a local encachement of the 
taxonomic information about the task, and is used to search for tasks by categories and together 
with taxonomic categories 809 in profile record 225 to match tasks and service providers. 
dispatch_prototype 909 indicates how system 101 is to deal with the task. For 
example, if the task is a question, system 101 may not actually assigned the task to any service 

25 provider, but instead, only post it, record service providers who provide acceptable solutions, 
and then allocate payment to them. 

The fields at 91 1 describe the task by name, description, and URL and if the task is to be 
public, that is, available to be solved by anyone who has access to system 101. 
30 public_directory specifies that the solution to the task is public, and consequently can 
be placed in a publicly-accessible directory in system 101. The fields at 913 contain task 
pricing and payment information; those at 915 contain values which indicate the state of the 
task. When the task is being performed by a single service provider, the fields indicated by 
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917 contain information about the provider. Included here are timestamps 919 for alterations 
of tables containing information about the provider and task. 

Continuing with task solution table 269, each such table has its own index 921 and its own 
update information 923; task_id 925 has as its value task_id 901 for task record 249 
that represents the task to which the solution belongs. owner_id 927 has as its value 
provider_state_id 1101 for provider state record 261 that represents the user, profile, 
task tuple to which the solution belongs. The fields at 929 contain status information about the 
solution; field 931 contains the task's solution when the solution is small enough to fit within 
task solution record 269; when that is not the case, flag 933 indicates that fact, and there will 
be one or more solution file table records 317, each of which has a field that contains the value 
of task_solut ion_id 921 and indicates one of the files that contains the solution. At 935, 
there are various time stamps: seen_time indicates the time at which the service requester 
last examined the task; the other two fields are time stamps for the task's status history record 
253 and solution history record 273 . 

jvaij^f rrin n t ? «-- h "" e rec " rH ™ 7 " egotiati ™ state rgcQr<< ^1. and negotiation history 

fr?r}T A FIG. 10 

The tables shown in FIG. 10 implement the arrangements in system 1 01 for pricing a solution. 
Pricing scheme record 307 contains the scheme chosen by the service requester for 
determining the service's price. The record is located from pricing_scheme__id in 913 
in the task's record 249, which has as its value a pricing_scheme_id 1001 for a pricing 
scheme record 307. Then come the modification record, a class field 1005 indicating the 
class of pricing schemes that this record belongs to, which in turn indicates what fields will be 
relevant, and then come the fields of pricing information 1006, which describe the mechanism 
used to determine the price, the highest bid (if a bidding system is used), the index of account 
record 205 for the successful bidder, and the commission for the providers of system 101. 

The current state of the price determination and a history of prior states are represented by 
records 311 and 265. Negotiation state record 311 represents the current state. Each user, 
profile, task tuple involved with a task has a record 31 1 and the tuple's provider state record 
261 includes the index of its record 311 at reference number 1109. The fields of negotiation 
state record 311 include an index 1007, the usual modification information 1009, the class of 
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the negotiation state record, polarity 1013, which indicates for an auction whether the bids 
are to move upwards or downwards, the index 1015 of the pricing scheme record 307 to 
which record 311 belongs, the service provider bid 1017 represented by the negotiation state 
record, and a time stamp 1019 for the most recent change in the negotiation history records for 
5 the negotiation. 

Each stage of the negotiation represented by negotiation state record 311 has a negotiation 
history record 265. The fields of this record include a key 1021, the usual modification 
information 1023, a field 1025 whose value is the key for the negotiation state record, a field 

10 1027 for the amount reached in the negotiation at the point in the negotiation represented by 
record 265, and a whocode field 1 029 which indicates whether the party making the move in 
the negotiation represented by the negotiation history record 265 was the service requester or 
the service provider. Together, records 307, 311, and 265 for the user, profile, task tuples 
involved with a task provide a complete audit trail of the negotiations which determined the 

15 price for which the service provider is to provide the service. 

Details of provider state record 261 and acti vity record 257: FIG. 1 1 

Provider state record 261 relates a user, profile tuple to a single task record 249, and thus 
represents a user, profile, task tuple in the system. At 1 101 is seen the index for the record and 

20 at 1103 the modification information. At 1105 are seen fields whose values are the index of 
the task record 249 and the index of the profile record 225 for the user, profile tuple, status 
1 1 07 contains the current status of the user, profile, task tuple represented by the record. In a 
preferred embodiment, the status depends on whether the user, profile pair of the tuple is 
functioning as a service requester or a service provider. Where the user, profile pair is a 

25 service requester, the statuses are: 

• pending . 

• authorizing 

• released 

• offers pending 
30 • assigned 

• solved 

• paid 

• expired 

33 



- 35 - 



WO 00/29989 



PCT/US99/27270 



Where the user, profile pair is a service provider, the statuses are: 

• uninvolved 

• assignment offered 

• assignment requested 

• assigned 

• assignment offer rejected 

• assignment request rejected 

• solved 

• solution released 

• modification requested 

• paid 

• expired 

• solution rejected 

The fields indicated at 1 109 contain the indices of the negotiation state record 3 1 1 for the user, 
profile, task tuple and of the solution record 269 for a solution provided by the user, profile, 
task tuple. price_paid field 1 1 1 indicates the price paid by the service requester for the 
service, the fields at 113 contain the expertise rating given the service provider, profile, task 
tuple, and the field of f er 1 1 15 is the most recent offer made by the service requester to the 
service provider for the task. The timestamps at 1 117 include the time at which the solution 
was seen by the service requester and the last update times for status history record 253 and 
solution record 269 for the service provider, profile, task tuple. tip_amount field 1119 
indicates the amount of any tip paid by the service requester to the service provider. 

Activity record 257 maintains payment information for a given user, profile, task tuple. Fields 
include the record's index 1121, modification information 1123, fields 1124 for indices for the 
task record 249 and provider state record 261 for the user, profile, task tuple, field 1125 
indicating the class of activity record 1125 (indicating how the fields in 1131 are to be 
interpreted), and field 1 127 containing the index of account record 257 for the provider of the 
service. The fields indicated by 1131, finally, contain payment information for the user, 
profile, task tuple. 

p r Ta ;ic of stat m 1u«"™ ™™* ™ hist0TV ?n m< ^ P * I<?Qori 40?; 

F I G, 12 
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A status history record 253 is produced each time the status of a task changes; records are 
made both for the task and for the user, profile, task tuple that caused the change. Thus, both 
task records 249 and provider state records 261 have one-to-many relationships with task 
records. As can be seen from the foregoing, the sequence of status history records for a task 
thus provides an audit trail for the task and the user, profile, task tuples involved with the task. 
The index of the record is in 1201; its revision tracking fields are shown at 1203; owner_id 
1205 is the index of task record 249 or provider state record 261 to which status history record 
253 belongs, status 1207 indicates the new status of the task. The values are the same as 
those for status field 1 107 in provider state table 261 . 

A solution history record 273 is produced each time a provider, profile, task tuple provides a 
new solution for the task. Fields 1209 and 121 1 are the record index and change information 
fields; field contains the index of solution record 269 for the provider, profile, task tuple. 
S olu'tion_text 1215 is a copy of solution_text field 931 from solution record 269 
for the task whose history is being recorded. 

A message record 409 is made each time a user of system 101 sends a message to another user 
thereof about a task, and is also made each time system 101 sends a message about a task to a 
user. Each record 409 has an index 1217 and modification information 1219; field 1221 is the 
index of task record 249 for the task that the message concerns, class field 1223 indicates 
the class the message belongs to. There are three classes: system message, requester message, 
provider message, text field 1225 contains the text of the message. The fields labeled 1227 
indicate the users that are concerned with the message as sender, recipient, or subject of the 
message. Each of the fields contains the index for the relevant user's account record 205. 
seen_time 1231 indicates the time that the recipient looked at the message, and the fields 
indicated by 1233 show whether the sender or recipient has deleted the message. As can be 
seen from the foregoing, message record 409 provides easy retrieval of messages by sender, 
recipient, subject, or task, and the sequence of messages for a task is part of the task's audit 
trail. 

Archiving and audit trails in database 125 

System 101 archives the current state of a task by setting a field in the task's task record 249 
to indicate that the task is archived and then making a copy of the state of the task when 
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archived. This copy is part of archive information 137. Subsequently (on a nightly or weekly 
basis, depending on task volume and system load) system 101 moves archived tasks to a 
replica of task table 247 which is in a different tablespace (done to optimize disk accesses and 
permit parallel query efficiency). When the archived task record 249 is moved, copies of the 
5 dababase records that are accessible via the task's index are also moved. Because nothing 
ever actually leaves the database and every action is recorded by the creation of a record in a 
table, an audit trail can be made simply by searching database 125 for the relevant information. 

Overview of database manipulation routines 115: FIG. 13 

10 FIG, 13 shows the routines used in a preferred embodiment to manipulate dispatch system 
database 1255. The routines are subdivided into the groups shown in FIG. 1. The following 
discussion will explain each routine's function and the principle tables in database 125 which 
are read or written by the routine. 

is !Viri(™itiP es H6 

• User registration routine 1301 makes an account record 205 for the user and if the user 
provides profile information, a profile record 225. If the user so indicates, routine 1301 
will also make one or more education records 217, expertise records 221, and payment 
method records 209 or 213. 

20 • Search users routine 1303 searches for user profiles by name or by taxonomic categories, 
i.e., by the kinds of expertise or education the user has. 

• view user info 1303 permits a user to view information from a profile table and from the 
education, expertise, and rating tables available through the profile table. 

• rate user info 1305 permits a user to rate another user's performance either as a service 
25 requester or as a service provider with regard to a task. The routine writes the rating to the 

provider state record for the user, profile, and task and also updates the relevant expertise 
rating record 229, 233, or 235 for the profile. 



30 



Task routines H7 

• post task routine 1 307 makes a provider state record 26 1 and a task record 249 for the user, 
profile tuple that is posting the task. 

• view task routine 1309 displays information from a task record 249 and from pricing 
scheme record 309 for the task record. 
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• search task routine 1311 searches for tasks by the taxonomic categories in the task records 
249. 

• bid on task 1313 creates a provider state record 261 for a provider, profile, task tuple, and 
makes a negotiation state record 313 for the tuple, and sends a message to the requester, 

5 profile, task tuple. In sending the message, send message routine 1325 is used and a 
message record 409 is created. 

• respond to bids 1315 alters pricing scheme record 309 to reflect the current state of the 
bidding, and when a bid is accepted, uses send message routine 1325 to send a message to 
the successful provider, profile tuple. 

10 • pay provider 1317 uses the information in pricing scheme record 309 for the task, in 
provider payment method table 211 for the provider, profile tuple, and in activity record 
207 for the requester, profile, task tuple to pay the provider for the service. 

SoMlOP routines 118 

1 5 • post solution routine 1319 creates a solution record 269, solution history record 273, and if 
necessary, a solution file record 3 17 for the solution for a provider, profile, task tuple and 
uses send message 1325 to send a message to the task's requester, profile tuple to indicate 
that a solution has been provided. 

• view solution routine 1321 views a solution for a task represented by a solution record 269, 
20 which may involve viewing the file specified by solution file record 317. In some 

instances, the solution will be ambiguated. 

• accept/reject solution routine 1323 creates a solution history record 273 and if the solution 
is accepted, uses pay provider routine 1317 to pay the successful provider, profile tuple. 
With either acceptance or rejection, the routine uses send message 1325 to send a message 

25 to the solution's provider, profile tuple. 

Mf Q<ra B e routines 119 

• send message 1325 sends a message to a user with regard to a task, creating a message 
record 409 as it does so. 

30 • view messages 1327 permits a user, profile, task tuple to view messages relevant to it and 
the task. 

A rr ^jy? routines 120 
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• search archives 1329 uses search users 1302, search task 1311, view user info 1303, view 
solution 1321, and view message 1329 to view archived information in database 125. 

Details of the user interface for system 101 
5 As previously explained, the user interface for system 101 is Web pages. In the following, 
exemplary portions of the user interface will be explained and related to database 125. 

When a user inputs the server address of server 109 into his or her browser, the first Web page 
10 he or she receives from server 109 is page 1401 shown in FIG. 1 . This page explains what the 
service dispatch system is, has a portion 1403 which permits already-registered users to log in 
and others to register, and has a tab bar 1405 for tabs for initial Web pages of other portions of 
the user interface for the service dispatch system. 



15 Re gistration : FTOs. 15 and 16 

Figs. 15 and 16 show the registration interface. Fig. 15 shows interface 1501 which collects a 
username and a password a 1503, an email address for use by system 101 at 1505, and a 
specification at 1507 concerning how emails are to be received. The information specified 
here becomes part of account record 205 for the new user. FIG. 16 shows interface 1601 
which collects the actual name at 1603 and location information at 1607 of the user and 
requests the name for a default profile record 225 at 1605. As shown in interface 1601, system 
101 protects the privacy of its users by never revealing the actual name of the user contained in 
account record. As shown at 1607, the user can select the parts of his or her location 
information which are to be publicly available. 



20 



25 



30 



p^tinp ? task- FlOs. 1 7 and 18 

FIGs. 17 and 18 show the interface that a service requester uses for posting a task. FIG. 18 
shows interface 1801 for defining the task. The task here is a question. At 1803, the task 
requester inputs the task title, a category for the task, a posted date, a price, and a description of 
the task. As seen at 1 803, the task requester can also specify a length of time left to respond to 
the task and can clarify the task in response to queries by service providers. 
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FIG. 17 shows the interface 1701 used to categorize the task and specify the price. At 1703, 
the service requester provides a primary category 1704 and selects from a list of subcategories 
1705. At 1706, the requester further characterizes the programming environment that the 
question is about. This information goes into task record 249 for the task. At 1707, the 
requester has set a fixed price of $30.00 for the task and system 101 is setting forth the 
payment terms. The information for the price is stored in pricing scheme record 309 belonging 
to the task. 

At 1807 and 1813 in FIG. 18 are shown the interfaces by means of which a service requester 
10 keeps track of solutions of the task. Bar 1807 indicates that the task's status is solved; the 
buttons at 181 1 permit the service requester to add a clarification if the solutions show that one 
is needed and to pay the service provider(s) if the results are satisfactory. At 1813 is shown the 
list of solutions which service providers have provided for the question and messages 
concerning the question. The information here comes from solution records 269 and message 
15 records 409 for the task. 

Afflircninc n tusk; F Trts 35 - 39 

When either the requester or system 101 has selected one or more profiles of service providers 
to solve the task, system 1 01 makes a provider state record 261 for each of the selected profiles 

20 so that the task is related to the profile and then sends the provider a message indicating that he 
or she has been selected. When the provider, in this case the one with the profile name 
"hoops", looks at the tasks for the profile, task notification interface 3501, shown in FIG. 35, 
appears. At 3503, the interface describes the task, the posting profile, the time of posting , the 
time left to perform the task, and the price. The information is of course from the requester's 

25 profile, the provider state record 261 for the requester, profile, task tuple, and the task record 
249 for the task. Since the provider has as yet taken no action relative to the task, status field 
3505 indicates that the status of the task for the provider is uninvolved. The buttons at 3505 let 
the provider either request to be assigned to the task or permits him or her to send a message to 
the requester with questions. At 3507 is shown the interface where the provider receives 

30 messages and writes his or her solution to the task. 

When the provider clicks on the request assignment button, interface 3601, shown in FIG. 36 
appears. There, at offer amount 3603, the provider inputs how much he or she wants to do the 
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task; at 3605, he or she writes a note indicating what he or she proposes to do. When he or she 
is satisfied, he or she clicks on the "submit" button. As a result of this action, system 101 
makes a message record 409 for the reply, updates negotiation state record 313 for the 
provider/profile/task tuple, and makes a status history record 253 indicating the transaction for 
5 the provider/profile/task tuple. 

FIG, 37 shows the interface 3701 that the requester uses to act on the provider's request to 
have the task assigned to him or her. At 3703, there is a table of action items for the task's 
requester profile. At 3705, there appears an item that indicates that the profile "hoops" has 

10 placed a bid of $33.00 to do the prime number computation task. At 3707, there is a table 
listing new messages received by the requester profile; shown at 3709 is the text of the 
message that "hoops" sent when he or she requested assignment. At 3711 appears a table of 
the status of recent tasks. The entry for the prime number task appears at 371 3. The status of 
the prime number task for the service requester profile is "pending", since no bids have as yet 

15 been accepted, 

FIG. 38 shows the interface that appears when the service requester clicks on the underlined 
portion of row 3705. Interface 3801 provides the task description including the current price 
at 3803; at 3805 is indicated that the task has the status "pending"; the add clarification button 

20 permits the service requester to add a clarification to a pending task. Under solutions and 
messages is seen the result of "hoops'" assignment request: there appear his or her profile 
name, the requested price, and the message 381 1 that accompanied the assignment request. AH 
of this information comes of course from the records made when the provider requested that 
the task be assigned to him or her. The service requester uses the buttons at 3809 to accept or 

25 reject the offer. Here, the requester is going to accept, so he or she clicks on the thumbs up 
button. The result of this is an updating of the requester, profile, task tuple's provider state 
record 261 and negotiation state record 313 to indicate the new status of the task and the 
creation of a new status history record 253 for the requester, profile, task tuple. System 101 
then notifies the provider profile of the assignment. 

30 

FIG. 39, finally shows the interface 3901that the provider uses to accept the assignment. To do 
so, the provider simply clicks on submit button 3907; if he or she desires to send a message 
along with the acceptance, he or she writes the message in box 3905. Clicking on submit 
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button 3907 changes the status of the task to "assigned" in provider state record 261 for both 
the requester, profile, task tuple and the provider, profile, task tuple. Status history records 253 
are also created for the two provider state records 261 and for task record 249. 

Arreting o r rejecting a solution: FIG. 19 

Interface 1901 is the interface for accepting or rejecting a solution. This interface appears 
when the service requester clicks on one of the solutions listed at 1813 in FIG. 18. At 1903 is 
shown the description of the solution, including the name of the service provider profile which 
submitted the solution, the time of submittal, and the text of the solution. For longer solutions, 
file uploads 1905 indicates where the service requester can find the solution. This information 
is from solution record 269 for the solution, and in the case of the file names, from solution file 
records 317. At 1907, the service requester may send a reply message to the service provider 
profile regarding the solution. At 1909, the service requester can respond to the solution by 
requesting a revision, sending a message, or simply rejecting the solution. In any case, the 
interaction in this screen results in the creation of a status history record 253 for the task. 
Acceptance of solutions for a task occurs when the service requester selects the pay button at 
1811 in FIG. 1 8. At that point, all solutions which have not been rejected are accepted. 

ftfltjpp the service providers: FIG. 20 

Interface 2001 is the interface for rating the service providers who provided solutions for the 
task. As seen at 2003, each provider has a row in a table, identified by the profile name for the 
profile the provider used in solving the task. The columns in the table permit the requesting 
user to rate the quality and timeliness of the solution and to provide a comment. This 
information goes into provider state record 261 for the profile and task and is periodically 
summarized for the profile in records in rating tables 229 and 233. 

A Un gating payments ? T" nn E service providers: FIG, 21 

A service requester may specify a maximum number of solutions for a fixed-price task and 
may divide the fixed price among the service providers. Additionally, the service provider 
may add a tip to the payment amount. Interface 2101 is the allocation and tip interface. Table 
2103 has a row 2105 for each of the service providers who solved the task. Each row has a set 
of buttons for assigning relative payments and a specification of how much the service 
provider will receive given the current allocation. Each row also has a field for specifying a tip 
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for the responder and a field for the total payment owed. Once the service requester has a 
satisfactory allocation, he or she enters the allocation and tips by pressing button 2107. The 
result of so doing is to set values in provider state record 261 for each of the user, profile 
tuples which provided a solution. 

5 

ftfnHinfl messages: FIG. 22 

FIG. 22 shows the messaging interface 2201 for sending messages between users of system 
101. Here, as shown at 2203, the service provider with the profile named ganesh has sent a 
message regarding the task question to ganesh to the task's service requester. The service 
to requester is writing a reply in box 2205; when finished, he or she can click on button 2207 to 
send the message to the service requester. The message from ganesh is of course contained 
in a message record 409, and the reply creates a new message record 409. 



Pftgrfap a protect: FIGS. 23-25 
15 Here, the project is a Java applet. Interface 2301 describes the new project. At 2303 the 
service requester specifies the name of the profile that is posting the project; at 2305, the 
service requester inputs the project title is input; at 2306, he or she inputs project details. At 
2309, the service requester selects a broad category for the project. 

20 Continuing with FIG. 24, there is shown the interface for selecting the manner in which the 
project will be priced. As shown at 2401, a preferred embodiment permits the service 
requester to specify that the project has a fixed, non-negotiable price, a fixed, negotiable price, 
or will be set by one of three bidding methods: reverse auction, sealed bidding, and Dutch 
auction. Here, the service requester has selected sealed bidding. 

25 

In FIG. 25 are shown interface 2501 for selecting subcategories to which the project belongs 
and interface 2509 for further specifying the price. In interface 2503, the broad category 
selected at 2309 is displayed, and list 2505 shows subcategories of the category displayed at 
2509. The service requester then characterizes the project by selecting one or more of the 
30 subcategories and specifying a programming environment for the code at 2507. At 2509, the 
service requester inputs the maximum price at 251 1 and the duration of bidding at 2513. 
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In response to the above inputs of information by the service requester, system 101 creates a 
new task record 249 for the task, a provider state record 261 for the service requester's profile 
and the task, a task category record 305 for the task, and a pricing scheme record 307 for the 
task. 

T >gW status interface for the service requester: FIGs. 26 and 34 

FIG. 26 shows task status interface 2601 for the service requester. The buttons at 2603 and 
2605 permit the user to post new projects or questions using the interfaces explained above. 
Table 2607 contains a row for each open task posted by the service provider. The row 
specifies the date the task was posted, the time left to completion, the task status, the task 
name, the category to which it belongs, and the price. The Released status here indicates that 
the task has been posted, but no one has yet bid on it. The information comes of course from 
the task record 249 and pricing scheme record 309 for the task. At 2609 is displayed a list of 
any closed tasks. 

FIG. 34 shows the interface 3401 that the service requester uses to view messages for the tasks 
that are relevant to the service provider. Table 3403 has a row for each open task message, 
with columns for an action taken by the recipient, the date of the message, the source and 
recipient, the message, and the name of the task it belongs to. As can be seen from the source- 
recipient column, messages may be exchanged between the service requester and the service 
providers or between the system and the service requester or service providers. The 
information in the table comes from the message records 409 for the tasks. 

.gfr ryice provider sele ction interface: FIG. 27 

System 101 will itself select one or more service providers for a service requester, with the 
selection being based on the categories assigned to the task by the service requester and the 
rating information maintained by system 101 about service providers, but also has the interface 
2701 shown in FIG. 27 for permitting the service requester to select the service provider. At 
2703, the service requester may select the service provider by the name of a profile belonging 
to the service provider; otherwise, the user may select categories from list 2705 indicating the 
kinds of expertise desired in the service provider, and system 101 will provide a list of service 
providers who have at least one of the kinds of expertise. A portion of the returned list is 
shown at 2709; each service provider has a row on the list and the row specifies the provider's 
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profile name, his or her expertises, his or her time with system 101, and his or her current 
rating. System 101 selects the service providers on the basis of taxonomic categories field 809 
in their profile record 225 and the information in table 2709 comes from profile record 225 for 
the service provider and from the associated rating records 229 and 223 and expertise records 
5 221. 

iS ftrvir e proy ider-task interface; FIGs. 28-3Q 

FIGs. 28 and 29 show the interface that a service provider uses to view the tasks that are 
available to a specific one of his or her profiles. In FIG. 28, interface 2801 permits the service 

10 provider to see the tasks that have been offered specifically to the profile (2803), tasks that are 
available to be done by this profile (2805), and tasks that the profile is involved with (2807). 
Involved here means that the profile has done some action with regard to the task. This 
information comes from the provider state records 261 for the profile and the task record 249 
associated with each provider state record. At 2809 , the service provider can view the tasks 

15 completed by the profile. Fig. 29 shows interface 2901 that the service provider can use to 
view the messages concerning a task that have been sent or received by the profile. The 
service provider can view open task messages at 2903 and closed task messages at 2905. The 
information comes from the message records 409 for the tasks with which the profile is 
involved. 



20 



25 



30 



FIG. 30 is the interface that a service provider uses to browse tasks generally. Interface 3001 
includes a search interface that permits the service provider to search for a task by pressing 
button 3007. The search may be by task ID, as shown at 3005, or by category, as shown at 
3009. In addition, interface 3001 includes a list 3011 of recently posted tasks which are 
available for solution by any service provider. Each task has a row in the list, with the row for 
a task including the posting date, the task's title, and the price. The information in the table 
row comes from the task record 249 for the task and the pricing scheme record for the task. 

Frfitinp accent records H profile records: FIGs. 31 and 32 

FIG. 31 shows the interface 3101 that a user of system 101 uses to edit his or her account 
record 205 and records related thereto. At 3103, the user gains entry to the interface for 
changing the login and contact information in account record 205; at 3105, the user can edit 
buyer payment method 209 for the account record; at 3107, the user can edit provider payment 
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method record 213 for the account record; at 3107, the user can also edit the education records 
27 1 and the expertise records 22 1 associated with the account record. 

FIG. 32 shows the interface 3201 that the user can employ to edit a profile record 225 
belonging to the user's account record 205. As shown at 3203, the user may make a new 
profile, edit an existing one, or make a default profile. At 3204 is shown a list of profiles 
belonging to the user. For each profile is listed the profile's name, the associated expertises, 
the date the profile was made, and the ratings for the profile as provider and buyer. The 
information being edited is contained in profile record 225 and the associated rating records 
0 229,233, and 237. 

Th f interface for viewin g the user's monetary account With SVStem )Q1 ; FIG. 33 
FIG. 33 shown interface 3101 for viewing the user's monetary account with system 101. At 
3303 is shown the table which summarizes the monetary transactions in the account, and at 
15 3305 is the interface for viewing a list of activities for the current account. The information in 
this table comes from the activity records 257 for a user. 

Conclusion 

The inventors of the present invention have disclosed to those skilled in the arts with which the 
20 service dispatch system is concerned the best method presently known to them of 
implementing the system. However, as will be immediately apparent to those skilled in the 
relevant arts, there are many ways of implementing the principles of the service dispatch 
system other than the one disclosed herein, and the implementation may vary according to the 
kinds of services being requested and provided. For example, in some implementations, 
25 service requesters and providers may interact directly with each other, rather than by means of 
profiles. In other implementations, the tasks may all have fixed prices, and in still others, 
bargaining techniques may be used other than those disclosed in the preferred embodiment 
Where the system is specialized to a particular small set of tasks, there may be no need for task 
categorization and matching of service requester and service provider by category and 
30 expertise. Other embodiments may also use other techniques for selecting a set of service 
providers to whom the task may be assigned. For example, the system might maintain a list 
of currently-available service providers that is ordered by date of last task completion and 
simply select the service provider who had gone longest without an assignment. 
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The techniques used for ambiguating task solutions and for dealing with unsatisfactory 
solutions may also vary with the kind of system. For example, with simple tasks, the service 
requester may be permitted only to accept or reject a solution. Payment systems can include 
5 any mechanism for ensuring that an accepted solution is paid for, and an embodiment may 
employ any mechanism for preserving information which provides the necessary audit trails 
for the embodiment. For example, where the solution is simple and there is no price 
negotiation, audit trails may be needed only to determine how much the service requester owes 
the system and how much the system owes the individual service providers. 

10 

While the Internet provides a particularly advantageous environment for users of the service 
dispatch system, the system can be used in any environment that gives the system an 
interactive interface to the user 

15 For all of the foregoing reasons, the Detailed Description is to be regarded as being in all 
respects exemplary and not restrictive, and the breadth of the invention disclosed herein is to 
be determined not from the Detailed Description, but rather from the claims as interpreted with 
the full breadth permitted by the patent laws. 

20 What is claimed is: 
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2 



5 



9 
10 



1. A method wherein a service requester employs a service dispatch system to obtain a 
solution to a task for a price, the requester having access to the service dispatch system via an 
interface and the method comprising the steps performed using the interactive 



3 interactive i 

4 interface of: 
sending the service dispatch system a description of the task; 



6 receiving an indication from the service dispatch system that the solution is available 

7 from at least one of a set of potential service providers assigned to the task by the service 

8 dispatch system; and 



indicating to the service dispatch system that the price is to be paid to the service 
providers in the set from whom the solution is available. 



1 2 A method wherein a service provider employs a service dispatch system to provide a 

2 service requestor with a solution to a task for a price, the provider having access to the serv,ce 

3 dispatch system via an interactive interface and the method comprising the steps performed 

4 using the interactive interface of: 

5 receiving a notification from the service dispatch system that the task is available for 



6 solution; 

7 indicating to the service dispatch system that the solution is available; and 

8 receiving the price from the service dispatch system.. 
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CREATE TABLE tbl_hd_account 



( 



hd_account_id 
mod_count 
time_entered 
time_updated 
user name 
password 

taxonomic_categones 

f irst_name 
middle^initial 
last_name 
prof ile_name 
street 

street2 

city 

state 

zip_code 

country 

email 

email2 

receive_email 
buyerjpay_method_id 
provider jpay__method_id 

birth_year 

nationality 

gender 

visible 

status 

current jprofile^id 

referer 

question 

answer 

referrer_id 

ref erral_id 

balance 

expertises_time 
educations_time 

escrow_total 
escrow_available 

prof iles_time 
tasks_time 
status_history_t ime 
activities_time 
upload_directory 




INTEGER NOT NULL 
INTEGER NOT NULL/ 
CHAR (12) NOT NULL, ? 
CHAR (12) NOT NULL^ 
CHAR (20) NOT NULL, 
CHAR (20) NOT NULL, 
CHAR(40) NULL, 
CHAR (20) NOT NULL, 
CHARd) NULL, 
CHAR (20) NOT NULL, 
CHAR(20) NULL, 
CHAR (4 0) NULL, 
CHAR (40) NULL, 
CHAR (20) NULL, 
CHAR (20) NULL, 
CHAR (10) NULL, 
CHAR (20) NULL, 
VARCHAR(IOO) NULL, 
VARCHAR(IOO) NULL, 
CHAR(D NULL, 
INTEGER NULL 

INTEGER NULL 

CHAR (4) NULL, \ 

CHAR(20) NULL, ( i I 
CHAR(l) NULL, C I 509 1 
CHAR (20) NULL,_^) p— 
CHAR(l) NULL,*,. ~ Ljil 



J ' ■ 1 — rz 

L, 5 L 



511 



INTEGER NULL, 
CHAR (10) NULL, 
VARCHAR(IOO) NULL 
VARCHAR(IOO) NULL 
CHAR (10) NULL, 
CHAR (10) NULL, , — — 
INTEGER NULL, | 515 



integer null, T 
integer null, 
INTEGER NULL," ? 
INTEGER NULL, _5 
integer null, 
integer null, 
integer null, 
integer null, 
CHAR (32) null 



517 




) ; 



205 
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CREATE TABLE tbl 

education_id 

mod — count 

time_entered 

time_updated 

owner_id 

institution 

starting_year 

ending_year 

degree_subject 

degree_level 

degree_year 

visible 

) ; 



education ( 

INTEGER NOT NULL, 



| 609 



INTh<j£.K wui 

INTEGER NOT NULL, J 
CHAR (12) NOT NULL, > 

CHAR (12) NOT NULL, J 

INTEGER NOT NULL, 
CHAR (40) NULL, 
CHAR<4) NULL, 
CHAR (4) NULL, 
CHAR (20) NULL, 
CHAR (24) NULL, 
CHAR(4) NULL, 
CHARd) NULL 



611 




211 



CREATE TABLE tbl^expert 
expertise_id 

mod_count 
time_entered 
time~updated 
owner_id 
priroary_categ 
secondary_categs 
expertise__notes 

expertise^duration 

certifications 

visible 

) ? 



ise ( 
INTEGER NOT NULL, 
INTEGER NOT NULL, 
CHAR (12) NOT NULL, 
CHAR (12) NOT NULL, 
INTEGER NOT NULL, 
CHAR (10) NOT NULL" 
CHAR (50) NULL, 
VARCHAR(4000) NULL 
CHAR (20) NULL, 
VARCHAR(IOOO) NULL, 
CHARd) NULL 
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CREATE TABLE tbl^pay, 
pay_method_id 
mod_count 
time_entered 
time_updated 

class 

credit^card^company 
credit cardjnumber 
crediCcard_exp.date 
credit_card_holder 
credit_card_zip_code 

check_st:reet 
check__street2 
check_city 
check_state 
check_zip_code 
check_country 
bank__name 
account^ umber 
swift_aba_number 

authjprice 
) ; 



tnethod ( 

INTEGER NOT NULL, 
INTEGER NOT NULL, 
CHAR (12) NULL, 
CHAR (12) NULL/i 
CHAR(l) NULL, f 70:> 
CHAR (20) NULL, 
CHAR (16) NULL, 
CHAR (8) NULL, 
VARCHARU00) NULL, 
CHAR (10) NULL, 
CHAR (40) NULL, 
CHAR (40) NULL, 
CHAR (20) NULL, 
CHAR (20) NULL, 
CHAR (10) NULL, 
CHAR (20) NULL, 
CHAR (40) NULL, 
CHAR (20) NULL, 
CHAR (20) NULL, 
INTEGER NULL 
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( 



CREATE TABLE tbl_profile 
prof ile_id 
mod_count 
tiroe_entered 
time_updated 
owner_id 
name 

taxonomic_categones 

email 
email2 

inherit_emails 
buyer pay_method_id 
provider_pay__method_id 

visible 
description 
expertise_rating_id 
conduct_rating_xd 
buyer_rating_id 
participation_rating 
buyer participation_rating 



INTEGER NOT NULL, 
INTEGER NOT NULL, IT%Q1 
CHAR (12) NOT NULL, 
CHAR (12) NOT NULL, 
INTEGER NOT NULL, 
CHAR (40) NOT NULL, 
CHAR (40) NULL, 
VARCHARdOO) NULL, 
VARCHAR(IOO) NULL, 
CHAR(l) NULL, — , 
INTEGER NULL, L 
INTEGER NULL^^J i gn 

CHAR (20) NULL, 1 

VARCHAR(4000) NULL, 
INTEGER, 
INTEGER, 
INTEGER, 
CHAR (10) NULL, 



CHAR (10) 



earliest_task_time 
latest_task_time 
expert ises_time 
educations_tiroe 

tasks_time 
status_history_time 

buyer_messages_time 

pr ovider_messages_time 

provider_states_time 

) ; 



CHAR (12) NULL, 
CHAR(12) NULL, 
integer null, 
integer null, 
integer null, 
integer null, 
integer null, 
integer null, 
integer null 




225 



CREATE TABLE tbl_rating ( 
table_rating_id 

mod_count 
time_entered 
time^updated 
class 

rating_total 
rating_count 
rating_average 

); 

229, 233, 237 



INTEGER NOT NULL, 
INTEGER NOT NULL, 
CHAR (12) NOT NULL, 
CHAR (12) NOT NUL r 

CHAR(l) NULL, 

INTEGER NULL, J 
INTEGER NULL, ? 
NUMBER NULL > 
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CREATE TABLE tbl_task ( 

task_id 

mod_count 

time_entered 

time_updated 

owner_id 

structured__category 
dispatchjprototype 

name 

description 
url 

public_directory 

pricingscheme_id 

buy e r_pay jnet hod_id 

buyer_status 

record_state 

class 

numbe r_o f _bind ing s 
seen_time 
max__incidents 
associated_contract_id 

provider_id 
commi s s ion_key 
provider_states_time 
status_history_time 
solutions_time 
transact ion_id 
clarif icationsp 
directjnotif ies 
solutions_count 

) ; 

CREATE TABLE tbl_task_ 
task_solution_id 
mod_count 
time_entered 

time_updated 

task_id 

owner _ id 

status 

aux_status 

solution_text 

files 

seen_time 

status_history_time 
solution^history^time 

> ; 

FIG. 9 



INTEGER NOT NULL/ 
INTEGER NOT NULL, 
CHAR (12) NOT NULL 
CHAR (12) NOT NULL 
INTEGER NOT NULW 
CHAR(40) NULL, | 907 

CHAR (10) NULL/* 

CHAR (60) NOT NULL, 
VARCHAR(4000) NOT NULL, 
CHAR (40) NULL, 
CHAR(l) NULL, 

INTEGER NOT NULL 

INTEGER NULL, 

CHAR(l) NULL, 

INTEGER NULL, 

CHAR(l) NOT NULL, 

INTEGER NULL, 

CHAR (12) NULL, 

INTEGER NULL, 

INTEGER NULL, 

INTEGER NULL, 

CHAR (20) NULL^ 



integer null, J r— — i / ■ 

integer null, H 919 ) U 917 
integer null/ ) ( 



integer null/ ) 

INTEGER NULL, 
INTEGER NULL, 
VARCHAR(400) null, 
INTEGER NULL 




249 



solution ( 

INTEGER NOT NULL 

INTEGER NOT NULI^ - 1 

CHAR(12) NULL, U 92 3 

CHAR(12) NULL/ ) j 1 

INTEGER NOT NULL/ 
INTEGER NOT NULL 
CHARd) NULL, 
CHAR(l) NULL* 
VARCHAR(4000> NO T NULL 
CHAR (1) NULL/ j 933 
CHAR (12) NUClT) I ' 
integer null, f 935 
integer null 3 1 
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CREATE TABLE tbl_pricinc 
pricing_scheme_id 
mod_count 
time_entered 
time_updated 
class 

maximum^ price 
f ixed_price_total 
starting_price 
auction_duration 
auction_time_unit 
high_bid 
high_bidder_id 
price_increment 
time_increment 
closingjprice 
commission 
); 307 

CREATE TABLE tbl_negotiat ion_state 



_scheme ( 
INTEGER NOT NULL/ 
INTEGER NOT NULL, 
CHAR (12) NOT NULL, 
CHAR (12) NOT NULL, 
CHAR(l) NOT NULL, 
INTEGER NULL, 
INTEGER NULL, 
INTEGER NULL, 
INTEGER NULL, 
CHAR (20) NULL, 
INTEGER NULL, 
INTEGER NULL, 
INTEGER NULL, 
INTEGER NULL, 
INTEGER NULL, 
INTEGER NULL 





( 



negotiation^ tat e_id 
mod_count 
time_entered 
time_updated 
class 
polarity 

pricing_scheme_pointer_id 
seller — bid 

negot ia t ion__hi s tory_t ime 
) ; 



ULL^ | , — , 

' — 



311 



INTEGER NOT NULL^ 
INTEGER NOT NULL 
CHAR (12) NULL 
CHAR (12) NULL _ 
CHAR<1) NOT NULL, 
CHAR (10) NULL, 
INTEGER NOT NULL,-* 
INTEGER NULL, 

integer null w , 

^| 1019 



1007 



1011 



1013 



I 1017 | 



1015 



CREATE TABLE tbl_negotiat ionjiistory ( 



negot iation_history_id 

mod__count 
time_entered 
time_updated 
owner_id 
amount 
whocode 
) ; 



INTEGER NOT NULL, 
INTEGER NOT NULL, 
CHAR (12) NOT NULL, 
CHAR (12) NOT NULL, 

INTEGER NOT NULL, 
INTEGER NOT NULL, 
CHAR(l) NOT NULL 
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CREATE TABLE tbljprovide 
provider_state_id 
mod__count 
time_entered 
time_updated 
task_id 
owner_id 
status 

negotiations_id 
solution_id 
price_paid 
r a t i n g __c omme n t 
expert ise_rating 
conduct_rating 
buyer_rating 
buyer ^comment 
offer 
seen — time 

status_history__time 
solutions_time 
tip amount 
); " 261 



r_state 
INTEGER 
INTEGER 
CHAR(12) 
CHAR (12) 
INTEGER 
INTEGER 
CHAR(l) 
INTEGER 
INTEGER 
INTEGER 
VARCHAR ( 
INTEGER 
INTEGER 
INTEGER 
VARCHAR < 
CHAR (10) 
CHAR (12) 
integer 
integer 
INTEGER 



< 

NOT NULL, 
NOT NULL, " 
NOT NULL, 
NOT NULL, 
NOT NULL, 
NOT NULL, 
NULL 
NULL 
NULL 
NULL, 

4000) NULL, 
NULL, 
NULL, 
NULL, 

4000) NULL, 




NULL / 

NULL 
null 
null 

NULL | | lt 9 



CREATE TABLE tbl_base_act ivity 

base_activity_id 

mod^count 

time_entered 

time__updated 

owner_id 

task_ id 

class 

provider_id 

hd_commission_amount 

other_commission_amount 

other_commission_code 

debit_amount 

credi t_ amount 

balance 

pay_method_ id 

type 

label 

escrow_available 

escrow_total 

notes 

); 157 
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CREATE TABLE tbl_status_history ( | 120] 

status_history_id INTEGER NOT NULL,^ 1 



mod count INTEGER NOT NULL," ) 

time entered CHAR(12) NOT NULL, U i 2 03 

time'updated CHAR (12) NOT NULL^J 

owner_id INTEGER NOT N ULL/ < 

status CHAR(l) NULL f—~ 

); 253 I 
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CREATE TABLE tbl_solut ion_history < j 1209 

solution_history_id INTEGER NOT NULL^LJlll 

mod_count 
time_entered 
time_updated 
owner_id 
solution_text 
); 273 



INTEGER NOT NULL, ) 
CHAR(12) NOT NULL, ^ ["T^ 

CHAR (12) NOT NULL_ L _J I 1 

INTEGER NOT NULL, 
VARCHAR{4000) NULL 1215 
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CREATE TABLE tbl_message 
message_id 
mod_count 
time_entered 
time — updated 
task_id 
class 
text 

sender_id 
recipient^ id 
party_regarding_id 

type " 
seen__time 

recipient_delete_code 
sender_delete_code 



( 

INTEGER 

INTEGER 

CHAR (12) 

CHAR (12) 

INTEGER 

CHAR(l) 

VARCHAR ( 

INTEGER 

INTEGER 

INTEGER 

CHAR(l) 

CHAR (12) 

INTEGER 

INTEGER 




NOT NULL, 
NOT NULL 
NULL, 
NULL, 
NOT NULL, 
NOT NULL, 
4000) NOT NULL7 

NOT NUlC") I 

NOT NULL, ? *227 

NULL, j . 

NULL, | 1229 ( 

NULL, 1 1 j 1231 

nullTc 



NULL J j 1233 



) ; 
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